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About  this  series 

This  white  paper  is  the  fourth  in  a  five-part  series  dedicated  to 
examining  problems  organizations  encounter  when  operating  in 
multimodel  environments  and  the  current  process  improvement 
approaches  such  organizations  need  to  consider.  It  examines 
the  current  state  of  the  practice  for  defining  process  architecture 
in  a  multimodel  environment,  methods  and  techniques  used  for 
architecture  development,  and  underlying  questions  for  a 
research  agenda  that  examines  the  relationship  of  technology 
strategy  and  composition  to  process  architecture  as  well  as  the 
interoperability  and  architectural  features  of  different  process 
technologies. 


The  rest  of  this  series  addresses,  in  more  detail,  each  phase  of 

the  reasoning  framework  for  technology  harmonization  in  a  multimodel  environment: 


•  The  1st  white  paper  addresses  the  benefits  of  a  harmonized  approach  when  implementing  more  than  one 
improvement  model,  standard,  or  other  technology  and  provides  a  high-level  description  and  underlying 
paradigms  of  a  reasoning  framework  for  technology  harmonization. 

•  The  2nd  white  paper  examines  the  approaches  needed  in  technology  selection  including  a  strategic  taxonomy, 
the  decision  authorities  associated  with  that  selection  at  all  levels  in  the  organization,  and  considerations  for 
thoughtful  sequencing  of  implementation  in  alignment  with  the  organization’s  mission,  goals,  and  objectives. 

•  The  3rd  white  paper  examines  technology  composition  in  relation  to  the  concepts  introduced  in  the  previous 
white  papers:  a  proposed  element  classification  taxonomy  to  make  technology  integration  effective  in  practice; 
and  the  role  of  technology  structures,  granularity  and  mappings  in  technology  composition. 

•  The  5th  white  paper  addresses  the  implementation  challenges  faced  by  process  improvement  professionals  in 
multimodel  environments,  where  it  becomes  necessary  to  coordinate  roles  and  responsibilities  of  the 
champions  for  different  technologies,  to  integrate  and  coordinate  training,  to  optimize  audits  and  appraisals, 
and  develop  an  integrated  approach  to  project  portfolio  management. 
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Our  approach  to  multimodel  harmonization  contains  several  areas  of  consideration: 

•  Alignment  of  organizational  and  improvement  objectives,  including 
identification  of  candidate  improvement  technologies1 

•  Strategic  categorization  of  improvement  technologies 

•  Design  of  improvement  solutions,  including 

-  Technology  composition  using  element  classification  and  other  tactical 
technology  connections 

-  Process  architecture 

•  Implementation  (or  execution)  of  multimodel  process  improvement  solutions, 
including  measurement  of  results 

Among  these  areas,  process  architecture  is  perhaps  the  most  crucial  in  our  research — 
it  is  the  underpinning  of  executed  processes,  the  means  by  which  products  are 
delivered;  however  its  underlying  methodologies  are  still  emerging  and  maturing. 
While  preliminary  work  has  been  conducted  to  address  the  strategic  selection  and 
composition  of  multiple  models,  the  current  understanding  of  technology 
interoperability  and  architectural  characteristics  is  insufficient  to  inform  effective 
process  composition  and  architecture.  Furthermore,  there  is  not  a  widely  held 
definition  of  process  architecture.  Nor  is  there  a  common  methodological  approach 
that  captures  all  of  the  needed  process  features  at  an  architectural  (rather  than 
descriptive  or  procedural)  level. 

Exacerbating  this  challenge,  globalization,  business  acquisition,  network-centric 
operations,  and  other  aspects  of  increasingly  complex  systems  being  built  across  the 
supply  chain — as  well  as  the  routine  emergence  of  new  process  technologies,  tools, 
and  regulations — require  increasingly  agile  and  robust  process  composition.  Such 
composition  will  benefit  from  the  existence  of  an  explicit  process  architecture  and 
design  as  well  as  from  a  clear  relationship  to  model  composition  and  compliance 
requirements;  however,  there  is  currently  no  common  definition  or  recommended 
approach. 

Yet,  numerous  organizations  have  sufficiently  adapted  available  diagramming 
techniques  to  serve  their  own  purposes — however,  these  are  “state  of  the  art” 
approaches  to  process  architecture,  not  “state  of  the  practice.”  Likewise,  some 
organizations  have  successfully  created  their  own  strategic  selections  and 
compositions  of  models  and  standards,  and  then  look  to  these  same  technologies  to 
serve  as  building  blocks  from  which  to  create  their  process  definitions.  In  today’s 
multimodel  environment,  this  is  a  complex  undertaking,  where  processes  must  be 
composed  to  incorporate  features  needed  for  both  compliance  and  mission  success. 
We  have  seen  that  innovators  and  organizations  with  the  most  advanced  multimodel 
strategies  and  tactics  often  use  process  architecture  as  a  starting  point,  not  an  ending 
point,  in  the  design  of  their  improvement  solutions.  However,  process  architecture 
can  be  informed  and  guided  by  strategic  categorization  and  tactical  composition  of 
models.  In  theory,  you  can,  at  least  partially,  generate  the  process  architecture  from 


1  In  this  series  of  white  papers,  we  use  the  terms  improvement  technologies ,  technologies ,  or  models 
somewhat  interchangeably  as  shorthand  when  we  are  referring  in  general  to  the  long  list  of 
reference  models,  standards,  best  practices,  regulatory  policies,  and  other  types  of  practice-based 
improvement  technologies  that  an  organization  may  use  simultaneously. 
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the  model  composition — if  the  model  interoperability  characteristics  are  understood 
and  the  tactical  connections  (overlaps  as  well  as  differentiating  features)  have  been 
fully  characterized.  These  realities  support  the  notion  that  the  harmonization 
reasoning  framework  involves  both  a  process  paradigm  and  an  aligned  vertical 
layering  of  the  design  and  implementation  aspects  of  the  harmonization. 

In  reality,  any  methods  to  support  the  development  of  a  process  architecture  and  its 
relationship  with  model  strategy  and  composition  are  currently  “state  of  the  art.”  In 
fact,  many  organizations  using  process  architecture  as  connoted  by  our 
harmonization  approach  consider  it  to  be  part  of  their  competitive  advantage  and  do 
not  often  share  many  details  publicly.  That  said,  in  this  4th  white  paper  of  our  series 
on  multimodel  process  improvement,  we  share  our  research  on  process  architecture 
and  provide: 

•  multiple  definitions  for  what  a  process  architecture  is 

•  highlights  of  mature  and  emerging  methods  that  can  be  leveraged  to  develop  one 

Because  research  for  process  architecture  is  still  emerging,  we  have  changed  the  tone 
of  this  white  paper  relative  to  the  others  in  this  series.  Our  purpose  is  to  raise 
awareness  about  process  architecture  and  why  it  is  important  and,  thereby,  to 
establish  a  foundation  (and  a  priority)  for  near-term  research. 


DEFINING  PROCESS  ARCHITECTURE 

In  the  engineering  of  software -intensive  systems,  we  typically  consider  the  product 
(software  and  system)  architecture.  This  consideration  is  not  restricted  to  software, 
however.  We  also  commonly  see  it  in  the  construction  of  buildings  (and  other 
“products”  of  architects  and  civil  engineers).  But...  do  we  see  architecture  applied  to 
the  creation  of  processes? 

Yes!  We  see  it  in  business  process  development  as  well  as  in  some  of  the  engineering 
process  models  with  which  we  are  familiar.  Here  is  a  sampling  of  process 
architecture  definitions: 

.  CMMI® 

Ordering,  interfaces,  interdependencies,  and  other  relationships  among  process 
elements  in  a  standard  process  [CMMI  DEV  1.2] 

•  Kasser 

Function  of  process  architecting  is  to  design,  set  up  and  continuously  optimize, 
the  process  for  the  development  of  the  specific  system  being  produced  [Kasser 
05] 

•  Business  Analysis  Body  of  Knowledge 

Processes  needed  to  conduct  business,  how  those  process  interact  and  how  they 
are  managed  and  modified  over  time. 

-  A  process  architecture  should  remain  fairly  intact  even  as  the  details  of 
process  execution  evolve  and  change.  [BA  Insight  06] 

These  definitions  are  different,  yet  complementary,  and  provide  a  foundation  for  an 
examination  of  process  architecture. 
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METHODS  AND  TECHNIQUES  TO 
DEVELOP  YOUR  ARCHITECTURE 


Many  researchers  have  considered  the  question  of  process  architecture,  and  have 
posed  higher  level  taxonomies  (of  similar  genre  to  those  we  have  already  put 
forward),  have  developed  specific  methods,  or  have  simply  raised  the  need  for  this 
topic  to  be  discussed.  Publications  that  have  generated  awareness,  ideas  and 
approaches  related  to  the  subject  area  include 

•  Armstrong’s  work  on  a  systems  approach  to  process  infrastructure  [Armstrong 
05] 

•  Kasser’s  work  on  process  architecting  as  a  needed  role  in  organizations  [Kasser 
05] 

•  Detailed  work  by  Halvorsen  et  al.  on  a  series  of  four  comparison  methods  to  use 
on  SPI  frameworks,  one  of  these  being  used  to  generate  a  taxonomy  of  25 
relevant  characteristics  [Halvorsen  01]. 

Others  who  have  performed  pioneering  work  in  this  area  include  Mutafelija,  who 
addressed  the  subject  of  process  architecture  views  and  properties  [Mutafelija  06], 
and  Bendell,  who  has  conducted  work  on  how  to  structure  business  process 
improvement  methods  [Bendell  05].  While  Osterweil’s  work  does  not  use  the  term 
“process  architecture,”  his  examination  of  macro  and  micro  processes  and  his 
development  of  the  Little  JIL  process  language  directly  relates  to  this  topic. 

[Osterweil  1]  [Osterweil  2]  [Avrunin] 

We  believe  developing  a  process  architecture  requires  taking  one  step  back  and 
considering  the  needed  properties  and  features.  Based  on  these  works  and  examples 
of  process  architectures  among  innovators  who  have  shared  their  cases  with  us,  here 
is  a  list  of  features  to  consider: 

•  Functional  properties,  including  classes,  flow,  and  attributes 

•  Inputs  and  Outputs,  including  flow  and  relationships 

•  Roles  and  responsibilities,  including  users  and  actors 

•  Information  flow 

•  Overall  interrelationships,  dependencies,  and  constraints 

The  content  of  these  features  can  be  informed  by  the  strategic  and  tactical  model 
classifications  as  well  as  model  composition  discussed  in  the  2nd  and  3rd  white  paper 
of  our  series.  Additionally,  there  are  numerous  diagramming  and  evaluation 
techniques  that  may  be  leveraged  from  within  and  outside  of  the  software 
engineering  discipline.  The  following  is  a  simple  list  of  possibilities  that  are  provided 
as  starting  points,  based  on  technical  and  logical  evaluations  as  well  as  observation  of 
practices  among  organizations  we  have  studied.  Through  future  research,  we  plan  to 
document  case  studies  and  develop  guidance  for  when  and  how  to  leverage  these 
methods. 
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Table  1:  Process  architecture  development  techniques 


Source  reference 

Techniques  that  may  be  leveraged  for 
process  architecture  development 

Design  for  Six  Sigma,  Design  for  Lean  Six 
Sigma,  and  other  robust  design  techniques 

Process  mapping  and  value  stream  mapping 

Software  and  related  engineering 
technologies 

■  Interoperability  principles  and  practices,  including  leveraging 
business  process  interoperability  and  approaches  to  service-oriented 
architectures.  Also,  in  addition  to  leveraging  design  methods, 
consider  adopting  a  “service  orientation”  philosophy  for  process 
architecture 

■  The  validated  architecture  process  of  the  Evolutionary  Process  for 
Integrating  COTS-Based  Systems  (EPIC)  [Albert  et  al.  02] 

■  The  Unified  Modeling  Language,  including  structure,  behavior,  and 
interaction  diagrams 

■  The  Little-JIL  Process  Language,  a  hierarchical  process 
decomposition  using  procedure  invocations  and  providing  for 
rigorous  definitions  and  automation.  [Osterweil  1]  [Osterweil  2] 

[Avrunin]  This  may  provide  enable  generation,  simulation  and 
validation  of  multimodel  based  processes. 

■  Software  architecture  technologies,  including  ATAM  and  QAW,  can 
be  leveraged  to  examine  the  properties  of  process  architectures  and 
the  relationship  to  their  ultimate  performance. 

Architectures  and  models  for  business 
process  management 

■  Architecture  of  Integrated  Information  Systems  (ARIS)  applied  to 
business  process  modeling  [Scheer  00;  Davis  01] 

■  Riva’s  process  definition  technique  (using  role-activity  diagrams)  and 
process  architecture  technique  [BA  Insight  06;  Ould  05] 

■  Goal-Oriented  Business  Process  Modeling  [Bider  05] 

Beer’s  Viable  Systems  Model 

Organizes  systems  in  a  way  that  meets  the  demands  of  surviving  in  the 
changing  environment;  subsystems  include  primary  activities, 
information  channels,  controls,  environmental  monitoring,  and  policy 
[Beer  85;  Beer  94;  Espejo  and  Harnden  89] 

Operations  Research 

Preliminary  investigations  have  indicated  that  the  operations  research 
body  of  knowledge  may  be  applicable.  This  needs  to  be  investigated  for 
applicability  to  software  and  systems  engineering. 
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Building  upon  the  emerging  and  existing  techniques  ( 

Table  1)  and  experience  reports  from  the  field,  we  believe  that  a  research  need  has 
RESEARCH  emerged  in  this  multimodel  context  that  has  not  benefited  from  focused  attention.  It 

DIRECTIONS  involves  the  examination  of  the  interoperability  and  architectural  features  of  different 

process  technologies.  In  light  of  the  challenges  facing  organizations  striving  to 
succeed  in  multimodel  integration,  an  advancement  of  our  understanding  of  these 
issues  has  now  become  essential,  and  raises  several  research  questions,  including: 

•  What  is  the  definition  of  “process  architecture,”  in  the  context  of  improvement 
technologies? 

What  is  the  appropriate  level  of  granularity  of  functional  properties  such  as 
classes,  flow,  attributes;  outputs;  information  flow;  relationships;  roles  & 
responsibilities;  and  constraints? 

Is  there  an  architecture  documentation  format  that  effectively  and 
efficiently  links  model  compositions  and  detailed  process  descriptions? 

How  do  we  reconcile  different  views  of  architecture  from  relevant  sources 
such  as  CMMI,  the  Business  Analysis  Body  of  Knowledge,  and  multiple, 
independent  researchers  such  as  Kasser,  Armstrong,  Osterweil,  and  others? 

•  How  is  process  architecture  derived  from  (or  distinct  from)  technology 
classification  and  composibility? 

Can  effective  technology  interoperability  and  composition  provide  or  lead 
to  the  process  architecture? 

What  level  of  granularity  of  technology  interoperability  and  composition  is 
really  needed?  Are  the  higher  level  taxonomies  currently  available 
sufficient? 

How  is  technology  interoperability  managed  relative  to  process 
architecture? 

Is  there  a  relationship  similar  to  what  exists  in  the  controls  system 
technology,  where  there  are  communications  standards  that  allow  different 
systems  and  instrumentation  to  be  assembled  into  the  same  system  with  the 
components  “communicating  across  a  common  backplane”? 

What  are  the  “-ilities”  of  process  that  need  to  be  addressed?  How  do  the 
architectural  and  interoperability  characteristics  of  the  reference  models 
affect  or  influence  the  architecture,  composition  and  “-ilities”  of  process? 

•  How  do  situational  and  system  complexity  affect  how  we  architect  and  compose 
a  process? 

Do  they  influence  prioritization/relevance  of  characteristics  of  technology 
architecture/interoperability  and  subsequently  influence  process 
performance? 

Do  we  need  the  capability  for  “predictable  assembly  of  process 
components”?  And  what  constitutes  a  “process  component”?  Is  it  a  reusable 
process  definition  and  procedure,  a  process  capability  embedded  within 
tools,  a  process  model  or  standard  embedded  within  tools,  and/or  something 
else? 
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The  objective  of  such  research  will  be  to  develop  the  underlying  principles  and 
process  characteristics  for  architecting  internal  processes,  in  the  context  of 
effectively  composed  combinations  of  technologies.  An  improved  understanding  of 
the  technologies’  interoperability  and  architectural  features  will  enable  practitioners 
to  characterize  technical  and  structural  relationships  among  technologies  and  to 
connect  this  with  the  creation  of  a  process  architecture.  Additionally,  it  will  inform 
researchers’  incorporation  of  interoperability  features  into  their  technologies. 
Therefore,  this  will  improve  adoption  effectiveness  and  robustness  in  the  face  of 
dynamically  composed  processes  that  are  anticipated  in  increasingly  complex 
product,  organizational,  and  supply  chain  environments. 


SUMMARY 

For  practitioners,  this  research  may  produce  outputs,  such  as  the  following. 

•  A  preliminary  taxonomy  of  existing  and  needed  interoperability  and  architectural 
characteristics  of  process  technologies. 

•  Identification  of  reusable  technologies  from  other  disciplines  for  creating 
architectures,  such  as  operations  research,  software  engineering  architecture 
notation/analysis  languages,  and  SoS  engineering. 

•  An  initial  collection  of  plausible  scenarios  reflecting  both  the  composition  of 
process  technologies  to  inform  organizational  process  definition  and  the 
composition  of  said  technologies  in  environments  that  are  dynamic  over  time. 
These  include  both  organizational  environments  (single  and  multiple 
organizations)  and  technical  environments. 

•  In  the  context  of  the  above,  the  recommended  features  and  characteristics  of  a 
process  architecture,  at  the  appropriate  level  of  granularity,  and  the 
corresponding  reconciliation  of  different  process  architecture  definitions. 

•  Pre -implementation  modeling  and  simulation  to  accompany  the  architecture  as  it 
is  designed  and  implemented. 

•  Mechanisms  to  analyze  the  behavior  of  a  system  with  respect  to  quality 
attributes,  which  will  enable  the  following: 

Prediction  of  behavior  before  process  systems  are  deployed 
Understanding  of  process  behavior  after  process  systems  are  deployed 
Design  decisions  during  design  and  during  evolution 
Process  architecture  has  been  observed  as  being  critical  to  the  success  within 
multimodel  process  improvement;  yet  it  is  currently  “state  of  the  art.”  Technologies 
from  within  and  outside  of  software  engineering  can  be  leveraged  to  create  a  robust 
architecture  that  is  easily  deployed  and  evolved  and  is  compliant  to  the  models  of 
choice.  More  work  needs  to  be  done  to  transform  process  architecture  approaches  to 
“state  of  the  practice.”  The  ideas  and  questions  described  in  this  paper  provide  a 
foundation  for  this  research. 
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PROCESS  ARCHITECTURE  IN  PRACTICE 


Internal  corporate  initiatives  at  companies  like  Lockheed  Martin  IS&GS  have  addressed  some  of  the 
issues  around  process  architecture  and  approaches  to  addressing  model  integration,  primarily  within 
the  framework  of  their  own  process  landscape.  Such  high-performing  organizations  are  creating,  in  a 
“state  of  the  art”  manner,  their  own  process  architectures.  The  good  practices  inherent  in  these 
proprietary  approaches  still  need  to  be  codified  for  wider  industry  usage,  thereby  becoming  “state  of 
the  practice.”  Consulting  companies  like  ISD  in  Brazil  have  developed  their  own  approaches  to  tackle 
multimodel  process  improvement  issues  at  a  strategic  model  composition  and  process  definition 
level,  and  have  begun  to  address  the  interoperability  and  process  architecture  problem.  [Byrnes  07] 

Following  are  highlights  from  Lockheed  IS&GS’s  approach  to  process  architecture  and  an  internal 
standard  operating  process.  This  is  from  their  case  study  which  is  more  completely  described  in 
CMMI  &  Six  Sigma:  Partners  in  Process  Improvement.  [Siviy  07-1] 

Lockheed  Martin  IS&GS’s  standard  operating  process,  which  eventually  became  known  as  the 
Program  Process  Standard  (PPS),  began  as  the  Required  Development  Process  (RDP)  (Note:  The 
name  change  resulted  from  the  ultimate  desire  to  eliminate  the  word  development  and  expand  the 
defined  process  into  different  types  of  programs.)  The  vision  associated  with  the  standard  operating 
process  was  that  it  makes  it  feasible  to  introduce  one  overall  process  to  the  organization.  It  also  had 
to  reflect  the  tasks  and  functions  necessary  to  fulfill  organizational  project  and  product  commitments. 
Additionally,  it  had  to  reflect  the  features  of  three  standards  of  interest  to  the  organization:  the  SW- 
CMM,  the  SE-CMM,  and  ISO  9000.  The  long-term  vision  was  that  new  standards,  process 
methodologies,  and  process  initiatives  would  be  integrated  with  this  single  operating  process,  thus 
allowing  the  organization  to  grow  and  evolve  its  capability  via  new  releases  of  its  standard  process. 

The  RDP  and  PPS  both  started  with  an  overall  workflow  diagram  of  what  processes  were  necessary 
for  the  organization.  Each  process  defined  was  then  given  a  functional  owner,  a  group  that  had 
primary  responsibility  for  the  process  itself.  Other  functions  that  also  had  responsibilities  for  tasks 
within  that  process  were  defined  as  support  functions.  A  table  was  generated  to  illustrate  functional 
responsibilities,  primary  or  support,  for  each  process.  The  process  was  then  dissected  and  tasks 
within  the  process  enumerated.  Once  tasks  were  enumerated,  entry  and  exit  criteria  as  well  as  inputs 
and  outputs  were  defined.  Once  the  entry  and  exit  criteria  and  inputs  and  outputs  were  represented 
by  the  functional  process  owners,  they  were  modeled  to  define  relationships  and  interfaces  between 
processes.  Every  entry  or  exit  criterion  needed  a  task  in  another  process.  Every  input  had  to  be  an 
output  from  some  process.  This  modeling  represented  not  only  a  simulation  of  the  workflow  but  it 
enabled  the  organization  to  illustrate  and  streamline  the  overall  process  implementation. 

The  PPS  architecture  started  with  describing  the  processes  that  the  projects  within  the  IS&GS 
organization  needed  to  operate.  This  was  coupled  with  a  mapping  of  the  process  to  the 
organization’s  business  objectives  and  goals.  The  document  was  designed  to  be  flexible  enough  to 
adapt  to  the  requirements  of  multiple  industry  standards  and  models.  The  organization  needed  a 
project-focused  document  that  would  be  simple  enough  to  be  accepted  but  comprehensive  enough  to 
meet  all  needs.  The  document  met  these  needs. 

Lockheed  Martin  IS&GS  used  process-mapping  techniques  to  evolve  the  initial  PPS  and  develop  an 
architecture  for  the  standard  process.  Figure  1  represents  a  high-level  view  of  the  overall  process 
map,  showing  specific  processes  linked  to  various  organizational  functions.  In  the  center  are  three 
concentric  circles,  but  the  circles  are  at  different  levels.  The  inner  circle  represents  the  IS&GS 
process  architecture,  the  next  circle  represents  the  organizational  process  assets,  and  the  outer 
circle  represents  the  programs’  implementation  of  the  process  assets.  The  outer  circle  defines  the 
lifecycle  of  a  system  of  systems,  from  procurement  through  transition  and  operations.  Two  groups  of 
processes  related  to  the  two  tiers  of  the  existing  version  of  the  PPS:  management  and  control 
(support  tasks)  and  program  implementation  (repeated  development/engineering  processes).  The 
program  management  and  control  processes,  listed  at  the  bottom  of  Error!  Reference  source  not  found., 
span  all  processes  within  the  PPS.  The  list  on  the  right  in  Figure  1  represents  program  implementation 
and  contains  all  processes — from  requirements  to  operations  and  maintenance — associated  with  the 
development,  delivery,  and  maintenance  of  an  actual  system.  The  list  on  the  left  was  added  to 
address  system -of-systems  concerns  and  the  system  support  activities,  which  has  now  become  very 
important  in  the  organization. 
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PROCESS  ARCHITECTURE  IN  PRACTICE  (CON’T) 


After  the  high-level  diagram  was  developed,  the  underlying  processes  were  defined  by  functional  process 
owners  and  subject  matter  experts.  Program  responsibilities  for  each  process  were  identified.  One  of  the 
challenges  the  process  designers  faced  was  what  level  of  detail  to  define.  Using  the  philosophies  of 
“keep  it  simple”  and  “the  process  should  reflect  how  we  do  business,”  they  created  a  process  template 
and  limited  each  process  description  to  one  page.  The  template  was  designed  to  focus  on  what  the 
program  needed  to  know:  purpose,  intent,  entry  and  exit  criteria,  inputs  and  outputs,  activities  and  tasks, 
with  the  latter  written  in  terms  of  what  to  do.  Where  a  SW-CMM  KPA  matched  the  process,  the  KPA  goal 
was  used  as  the  primary  reference  for  the  process  purpose.  The  KPA  practices  helped  identify  the 
needed  process  activities. 


Integrated  Logistics  Support  (ILS) 
SoS  Readiness 
Analysis  &  Modeling 


Mission  Requirement  &  Architecture  Definition 
SoS  Requirement  &  Architecture  Definition 
System  Requirements  Analysis 
Architecture-Based  Design 
Detailed  Design 
Code  &  Unit  Test 

Hardware  Assembly  &  Unit  Verification 
Product  Integration  &  Verification 
System  Integration  &  Verification 
Delivery  &  Installation 
SoS  Integration  &  Verification 
Transition  to  Operations 
Operations  &  Maintenance 


Program  Management  &  Control  Quality 

Contract  Management  Risk/Opportunity  Management 

Subcontract  Management  Quantitative  Management 

Program  Finance  Configuration/Data  Management 

Supplier  Management  Decision  Analysis 


Figure  1 :  LMCO  IS&GS  process  architecture 

A  small  process  group,  comprising  standards  experts,  then  mapped  the  process  standard  to  the  SW- 
CMM,  the  SE-CMM,  and  ISO  9000.  The  book  containing  the  workflow  diagrams  became  the  minimum 
mandatory  set  of  processes  for  all  programs.  Each  process  was  identified  as  part  of  management, 
engineering,  or  support/sustainment.  Each  activity  within  the  process  could  be  mapped  to  a 
recommended  procedure  within  the  process  asset  library.  The  organization  did  not  require  the  use  of 
these  procedures,  but  if  they  were  used,  full  compliance  to  the  PPS  would  be  assured.  However,  the 
procedures  could  be  tailored  and  still  meet  the  intent  of  the  process  purpose  (the  required  portion  of  the 
process).  By  design,  the  organization  could  follow  one  document,  and  the  reward  would  be  compliance  to 
the  SW-CMM,  the  SE-CMM,  and  ISO. 

The  product  suite  also  included  a  compliance  matrix,  which  each  program  was  required  to  complete, 
demonstrating:  how  the  program  was  compliant  (pointers  to  program  procedures),  which  processes  were 
being  tailored,  and  which  of  those  processes  needed  waivers.  A  template  was  then  created  for  a  typical 
program  plan  based  on  the  standard  process,  with  elaborations  on  procedures  that  programs  could  adopt 
in  order  to  assure  compliance.  A  program  plan  was  required  on  all  programs. 

After  the  foundational  elements  of  the  process  improvement  program  were  solidly  in  place  and  in  a 
routine  two-year  review  cycle,  and  as  the  organization  evolved  via  organic  growth  and  organizational 
acquisitions,  the  PPS  was  expanded  to  include  tailoring  guidelines  based  on  program  type;  the  list  of 
program  types  was  updated  as  well.  For  instance,  program  types  that  did  not  include  full-scale  software 
development  were  explicitly  included,  such  as  operations  and  maintenance,  support,  and  special  studies. 
....  Templates  for  the  PPS  Compliance  Matrix  and  Program  Plan  were  defined  for  each  program  type. 
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